﻿<%@ Page Language="C#" AutoEventWireup="true" CodeBehind="ScopeManagement_QualityStatement.aspx.cs" Inherits="PMP.Documentation.ScopeManagement_QualityStatement" %>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns="http://www.w3.org/1999/xhtml" >
<head runat="server">
    <title>Requirement Quality Statement & Guidelines</title>
    <style type="text/css">
        .style1
        {
            width: 100%;
        }
        .style2
        {
            text-align: center;
            height: 23px;
        }
        .style3
        {
            height: 42px;
        }
        .style4
        {
            height: 23px;
        }
        .style5
        {
            text-align: center;
            height: 23px;
            width: 36px;
        }
        .style6
        {
            height: 23px;
            width: 36px;
        }
        .style7
        {
            width: 36px;
        }
        .style8
        {
            width: 36px;
            height: 42px;
        }
    </style>
</head>
<body>
    <form id="form1" runat="server">
    <div>
    
        <table class="style1" 
            style="padding: inherit; margin: inherit; border: thin solid #00FFFF;">
            <tr>
                <th class="style5">
                    Score</th>
                <th class="style2">
                    Characteristics</th>
                <th class="style2">
                    Statements</th>
            </tr>
            <tr>
                <td style="text-align: center;border-top-style:solid;border-bottom-style:solid; border: thin" class="style6">
                    1</td>
                <td class="style4">
                    Correct</td>
                <td class="style4">
                    <span class="Apple-style-span" 
                        style="color: rgb(0, 0, 0); font-family: 'Times New Roman'; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; ">
                    Each requirement must accurately describe the functionality to be delivered.</span></td>
            </tr>
            <tr>
                <td style="text-align: center" class="style7">
                    2</td>
                <td>
                    Feasible</td>
                <td>
                    It must be possible to implement each requirement within the known capabilities 
                    and limitations of the system and its environment.</td>
            </tr>
            <tr>
                <td style="text-align: center" class="style8">
                    3</td>
                <td class="style3">
                    Necessary</td>
                <td class="style3">
                    Each requirement should document something the customers really need or 
                    something that is required for conformance to an external requirement, an 
                    external interface, or a standard.</td>
            </tr>
            <tr>
                <td rowspan="2" style="text-align: center" class="style7">
                    4</td>
                <td>
                    Unambiguous</td>
                <td>
                    The reader of a requirement statement should be able to draw only one 
                    interpretation of it.</td>
            </tr>
            <tr>
                <td class="style3">
                    Verifiable</td>
                <td class="style3">
                    See whether you can devise tests or use other verification approaches, such as 
                    inspection or demonstration, to determine whether each requirement is properly 
                    implemented in the product.</td>
            </tr>
            <tr>
                <td rowspan="2" style="text-align: center" class="style7">
                    5</td>
                <td>
                    Complete</td>
                <td>
                    No requirements or necessary information should be missing.</td>
            </tr>
            <tr>
                <td>
                    Prioritized</td>
                <td>
                    Assign an implementation priority to each requirement, feature, or use case to 
                    indicate how essential it is to include it in a particular product release.</td>
            </tr>
        </table>
    <br />
<table class="style1" style="border: thin solid #00FFFF">
    <tr>
        <td style="text-align: center">
            Guidelines</td>
    </tr>
    <tr>
        <td>
            Keep sentences and paragraphs short. Use the active voice. Use proper grammar, 
            spelling, and punctuation. Use terms consistently and define them in a glossary 
            or data dictionary.</td>
    </tr>
    <tr>
        <td>
            To see if a requirement statement is sufficiently well defined, read it from the 
            developer’s perspective. Mentally add the phrase, &quot;call me when you’re done&quot; to 
            the end of the requirement and see if that makes you nervous. In other words, 
            would you need additional clarification from the SRS author to understand the 
            requirement well enough to design and implement it? If so, that requirement 
            should be elaborated before proceeding with construction.</td>
    </tr>
    <tr>
        <td>
            Requirement authors often struggle to find the right level of granularity. Avoid 
            long narrative paragraphs that contain multiple requirements. A helpful 
            granularity guideline is to write individually testable requirements. If you can 
            think of a small number of related tests to verify correct implementation of a 
            requirement, it is probably written at the right level of detail. If you 
            envision many different kinds of tests, perhaps several requirements have been 
            lumped together and should be separated.</td>
    </tr>
    <tr>
        <td>
            Watch out for multiple requirements that have been aggregated into a single 
            statement. Conjunctions like &quot;and&quot; and &quot;or&quot; in a requirement suggest that 
            several requirements have been combined. Never use &quot;and/or&quot; in a requirement 
            statement.</td>
    </tr>
    <tr>
        <td>
            Write requirements at a consistent level of detail throughout the document. I 
            have seen requirements specifications that varied widely in their scope. For 
            example, &quot;A valid color code shall be R for red&quot; and &quot;A valid color code shall 
            be G for green&quot; might be split out as separate requirements, while &quot;The product 
            shall respond to editing directives entered by voice&quot; describes an entire 
            subsystem, not a single functional requirement.</td>
    </tr>
    <tr>
        <td>
            Avoid stating requirements redundantly in the SRS. While including the same 
            requirement in multiple places may make the document easier to read, it also 
            makes maintenance of the document more difficult. The multiple instances of the 
            requirement all have to be updated at the same time, lest an inconsistency creep 
            in.</td>
    </tr>
</table>
<p>
    Reference: <a href="http://www.processimpact.com/articles/qualreqs.html">
    http://www.processimpact.com/articles/qualreqs.html</a></p>
    </div>
    </form>
</body>
</html>
